This Page Is Inserted by IFW Operations 
and is not a part of the Official Record 



BEST AVAILABLE IMAGES 



Defective images within this document are accurate representations of 
the original documents submitted by the applicant. 

Defects in the images may include (but are not limited to): 



BLACK BORDERS 

TEXT CUT OFF AT TOP, BOTTOM OR SIDES 
FADED TEXT 
ILLEGIBLE TEXT 
SKEWED/SLANTED IMAGES 
COLORED PHOTOS 

BLACK OR VERY BLACK AND WHITE DARK PHOTOS 
GRAY SCALE DOCUMENTS 



IMAGES ARE BEST AVAILABLE COPY. 



As rescanning documents will not correct images, 
Please do not report the images to the 
Image Problem Mailbox. 



ra UK Patent Application m,GB ,,,2 360 867 ra A 



(43) Date of A Publication 03.10.2001 



(21) Application No 0116957.2 

(22) Date of Filing 11.07.2001 



(30) Priority Data 
(31) 0017044 



(32) 11.07.2000 (33) GB 



(71) Applicant(s) 

Newt Limited 

(Incorporated in the United Kingdom) 

Cobbins, Blackheath, GUILDFORD, Surrey, GU4 8RB, 

United Kingdom 

(72) Inventorls) 

Hugh Michael O'Donnell 
Bruce Jeremy Nielsen 

(74) Agent and/or Address for Service 
David Keltie Associates 
12 New Fetter Lane, LONDON, EC4A 1AG, 
United Kingdom 



(51) INT CL 7 

G06F 17/60 // G07F 7/08 7/10 

(52) UK CL (Edition S ) 

G4V VAC 



(56) Documents Cited 
EP 1001388 A2 



US 6019393 A US 4396985 A 



(58) Field of Search 

UK CL (Edition S > G4V VAC 

INT CL 7 G06F 17/60 , G07F 7/08 7/10 

Online: EPODOC, JAPIO, WPI 



(54) Abstract Title 

Payment transactions 



(57) A method of authorising a payment transaction 
comprises receiving data relating to a customer's 
transaction card, and data relating to an original amount of 
the payment transaction; presenting the original amount 
data to the customer such that a gratuity amount can be 
determined and in response thereto receiving data relating 
to the gratuity amount; establishing a link with an acquirer 
such as a financial transaction authorising entity via a 
telecommunication network and seeking online 
authorisation for the payment transaction by transmitting 
the transaction card data and data relating to a value of the 
transaction and generating and providing receipt data to 
the customer. The transaction value comprises the gratuity 
amount and the original amount and the receipt data 
confirms authorisation of the payment transaction at the 
transaction value when the transaction has been 
authorised. A method of authorising concurrent payment 
transactions such as may be generated by multiple mobile 
handsets and a base terminal is also described. 
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IMPROVEMENTS RELATING TO THE SECURITY OF PAYMENT 

TRANSACTIONS 

The present invention concerns improvements relating to the security of payment 
5 transactions and provides, more specifically, though not exclusively, a method and 
apparatus for authorising electronic payment transactions such as those suitable for 
implementation by the APACS standards in the UK, where the amount to be paid may 
incorporate a gratuity. 

10 Payment by credit or debit card, also known as electronic fund transfer (EFT), is 
rapidly becoming the preferred method of payment in many countries around the 
world. The number of payment cards issued is predicted to soar over the coming years, 
along with the number of purchases made using such cards. There are, however, 
serious concerns regarding the security of EFT systems and their robustness to fraud. 

15 

Debt arising from payment card fraud is generally met by the payment card issuing 
companies, but cardholders unwittingly pay for any unauthorised transactions that they 
fail to identify. Most cardholders, on receiving their monthly payment card statements, 
briefly check that their consumer activities are properly reflected. Few, however, go so 
20 far as retaining all of their receipts and marrying them up with the statement entries 
and so fraudulent transactions- associated with genuine purchases often evade 
detection. More particularly, and to the surprise of many cardholders, EFT transactions 
which support gratuity payments are inherently susceptible to discrete manipulation 
because of the underlying processing systems which are employed. 

25 

Merchants who wish to accept EFT payments must install a terminal for authorising 
electronic fund transfers at the point of sale (EFTPOS). An EFTPOS terminal typically 
comprises a payment card reader device, an operator input device such as a keypadj an 
output display screen, an EFT processing engine, a database for recording transaction 
30 details, a modem and a printer for printing off transaction slips and receipts. Each 
EFTPOS terminal connects to the host terminals of so-called acquirers, which are 



responsible for the electronic data capture of one or more credit/debit card issuing 
companies. The connection is made via an EFT network, such as a hard-wired 
telephone network. 

5 After payment card details and the amount to be paid have been entered, the merchant 
terminal contacts the relevant acquirer host terminal for authorisation of the payment. 
The information relating to the payment, including an authorisation code received from 
the acquirer host terminal, is stored locally at the merchant terminal until the 
transaction data is polled from the merchant terminal at a later stage. By polling it is 
10 meant a process whereby an acquirer host terminal addresses a merchant terminal, 
establishing a communications link across an EFT network, such that the merchant 
terminal is able to send data back to the acquirer host terminal on demand. The 
advantage of polling is that it can be carried out at a time suitable for the acquirer host 
terminal, usually at a time of low transaction activity. 

15 

Organisations which oversee the use of EFT networks for payment transactions impose 
certain governing standards and the EFTPOS terminals must be configured 
accordingly. For example, use of EFT networks in the UK is overseen by the 
Association for Payment Clearing Services (APACS). The associated standards are 

20 referred to as APACS n v.w, where n is the number by which the standard is 
referenced and m is its version number. The current standards in the UK which 
facilitate gratuity payments by credit or debit cards are APACS 30 v. 15, which is 
concerned with obtaining authorisation for electronic payment transactions, in 
conjunction with APACS 50 v. 15, which is concerned with the polling of authorised 

25 electronic payment transaction data. These standards and the problems associated with 
them are explained in more detail below, but it is to be appreciated that gratuity 
payments are supported by equivalent standards in other countries around the world. 

Consider a customer who, on being presented with a bill in a restaurant, elects to pay 
30 by EFT and provides a payment card. The payment card is taken away to the 
merchant's EFTPOS terminal where the payment card details and a sale amount are 



2 



entered and stored. In accordance with the APACS 30 standard, this information, 
together with a merchant ID, is sent as an authorisation request to the appropriate 
acquirer host terminal via the EFT network. On receiving the request the acquirer host 
terminal accesses the cardholder's account and, if the card is valid and sufficient funds 
5 are available, generates a code authorising payment to the merchant. The authorisation 
code is transmitted back to the merchant terminal and prompts the printing of an 
authorised transaction slip. This slip, together with a carbon copy backing, is removed 
and presented to the cardholder for signature. 

10 An example of an authorised payment transaction slip 10 is shown in Figure 1. The 
name and address of the merchant 12 are displayed at the head of the slip. The 
payment card details 14, including its type, number, expiry date and issue number, are 
then stated below, followed by a sale amount 16. Fields for a gratuity 18 and a final 
total amount 20 are to be completed by the cardholder, as is a signature field 22 where 

15 the cardholder confirms that their payment account should be debited as indicated on 
the slip. The signature field is followed by the acquirer's authorisation code 23. 
Finally, additional information about the transaction 24, such as the date and time 25, 
the merchant terminal number 26, the merchant ID 27, the receipt number 28 and the 
reference number 29 is printed at the bottom of the slip. 

20 

After the cardholder has completed the authorised transaction slip 10, the cardholder's 
signature is compared to that written on the payment card as a local security check. 
The cardholder is then handed the transaction slip 10, whilst the carbon copy is 
retained by the merchant. 

25 

As an alternative to carbon copy backing slips, a first version of an authorised 
transaction slip as shown in Figure 1 may be printed, completed by the cardholder and 
retained by the merchant, but a second version may subsequently be printed showing 
the total amount to be paid in the transaction. The second version does not require the 
30 cardholder's signature, as it is merely a confirmatory statement of what the cardholder 
has agreed to, and is therefore deemed more secure. 



3 



Although the merchant has been provided with an authorisation code for the sub-total 
16, the final total 20 will exceed this if the cardholder has elected to include a gratuity 
1 8. Rather than requiring the merchant to contact the acquirer for further authorisation, 
5 the APACS 30 standard permits authorisation codes 23 to extend to final total amounts 
20 which lie within a percentage of the authorised sale amount 16, which is typically 
15%. Thus, by referring to the carbon copy of the authorised transaction slip 10, the 
merchant is able to recall the transaction details using the reference number 29 from 
the database stored on the EFTPOS terminal and replace the authorised sale amount 16 

10 with the new total amount 20. This 'tolerance' of authorisation codes 23 prevents the 
cardholder from being unduly delayed at the transaction site, minimises the amount of 
processing to be performed by the merchant terminal and also helps to restrict 'traffic' 
on the EFT networks. However, the APACS 30 standard dictates that merchants must 
seek additional authorisation, or 're-auth', for final totals 20 which fall beyond the 

1 5 permitted tolerance. 

Finally, in accordance with the APACS 50 standard, the merchant's EFTPOS terminal 
is polled by the acquirer host terminals at a predetermined time (usually late at night), 
instigating an upload of details for all of the transactions which have been authorised 
20 and completed through it for subsequent settlement. 

Unfortunately present systems which facilitate electronic gratuity payments, as 
described above, are open to fraudulent abuse. As a matter of custom cardholders 
generally make gratuity payments which are 10% of the sub-total amount 16. 

25 Unscrupulous merchant staff can tamper with gratuity amounts 18 and final totals 20 
shown on carbon copy transaction slips before passing them on to an EFTPOS 
terminal operator, thereby increasing the pay that will be awarded to them in respect of 
the transactions by the merchant. Current systems often fail to alert the merchant, 
acquirer or card issuer to this type of fraud and it is becoming an increasingly common 

30 practice which merchants are keen to stamp out as it is highly damaging to their 
reputations. If stringent accountancy checks are not enforced, it is also possible for 
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terminal operators, prior to polling by the acquirer host terminals, to elevate final totals 
20 to the maximum amount that they think will evade detection. Indeed, this latter 
practice is conducted as a matter of routine in some establishments prior to its 
discovery. 

5 

Detection of this particular fraud is highly reliant on cardholders vigilantly policing 
their payment card statements. However, because the fraudulent increases are 
relatively small (say 5%) they are often difficult to detect and, in any event, many 
transaction slips are absent-mindedly discarded so that comparison with the intended 
10 amount cannot be made. Even if the fraud is noticed, a cardholder may fail to report it 
as they perceive the recovery of funds to be a time-consuming process and not worth 
pursuing if the amount involved is relatively small. 

There are also inherent disadvantages associated with the polling of information from 
15 merchant terminals. For example, the failure rate of polling processes is estimated to 
be around 8%. Such failures cause delays in settlement of the transaction funds which 
can seriously affect merchant cash flow and, in addition, any interest which would 
have accumulated in the merchant's account is lost. There are also significant charges 
associated with polling itself - merchants are typically charged between £10 and £15 
20 per month for each of their EFTPOS terminals. A merchant's income is further 
reduced if a final total exceeds an authorised tolerance and authorisation is refused 
when the 're-auth 1 procedure is executed; payment from the acquirer for the gratuity 
amount is then irretrievably lost. 

25 It is desired to overcome or substantially reduce some of the abovementioned 
problems. More specifically, it is desired to provide a method and an apparatus for 
authorising and effecting electronic payment transactions which offer improved 
resistance to fraud committed at merchant sites, particularly where gratuity payments 
are concerned. 

30 
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The inventors of the present invention are the first to appreciate that the established 
practice of seeking a gratuity from a customer after a transaction amount has been 
authorised is not necessary and is the root cause of the disadvantages described above. 
Accordingly, the present invention resides in the appreciation that an improved 
5 authorisation process for electronic payment transactions, which incorporate gratuity 
payments, can be achieved simply by determining the total amount that is to be paid 
electronically prior to obtaining authorisation for a transaction from an acquirer. 

Whilst at first sight this concept may appear to be a relatively trivial and obvious 
10 variation from the existing procedure, it is to be appreciated that it provides significant 
advantages over known methods which are described in detail later. In addition, this 
variation is a complete departure from the existing direction of developments in this 
field of technology, which are to improving the various polling techniques utilised 
with existing payment transactions. Rather, the present invention is such a fundamental 
15 divergence from the direction of development in this field that it does not suffer any of 
the problems associated with polling at all. 

More specifically, according to one aspect of the present invention there is provided a 
method of authorising a payment transaction, the method comprising: receiving data 

20 relating to a customer's transaction card, and data relating to an original amount of the 
payment transaction; presenting the original amount data to the customer such that a 
gratuity amount may be added and in response thereto receiving data relating to the 
gratuity amount; establishing a link with an acquirer via a telecommunications network 
and seeking online authorisation for the payment transaction by transmitting the 

25 transaction card data and data relating to a value of the transaction, the transaction 
value comprising the gratuity amount and the original amount; and generating and 
providing receipt data to the customer, the receipt data confirming authorisation of the 
payment transaction at the transaction value when the transaction has been authorised. 
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Here the term Acquirer* is intended to include any entity acting as a financial 
transaction handling proxy which has the right to authorise transactions on an 
acquirer's behalf. 



5 By establishing the value of the payment transaction in this way, authorisation can be 
obtained for the total amount that is to be paid, comprising the original amount and the 
gratuity amount, rather than just for the original amount as is the practice in the prior 
art. The present invention makes the practice of issuing authorisations with which 
inherent tolerances are associated, permitting post-authorisation manipulation of 

10 transaction values, redundant. Hence, a whole level of post-authorisation processing 
conducted at the merchant site is removed, such that merchant staff are no longer 
presented with a legitimate opportunity to manipulate the values of payment 
transactions subsequent to their receiving authorisation. Given that those opportunities 
have previously been exploited for fraudulent purposes, it is apparent that the present 

15 invention offers improved security over those methods of transaction authorisation 
which are known from the prior art. 

In addition to security considerations, the present invention can also be implemented 
by acquirers at a significantly reduced cost compared to that spent on implementing 

20 prior art systems. Since transactions do not need to be recalled for completion the 
transaction details are transmitted to the acquirer at the time of seeking authorisation 
for the total transaction amount, the polling processes of the prior art are also made 
obsolete by the present invention. The costs associated with developing, implementing 
and maintaining a polling system are considerable; for example, a large back office 

25 support staff is typically required. 

Preferably, the customer transaction card data is stored on a personal item of the 
customer and the method further comprises obtaining the transaction card data from 
the personal item for the purposes of authorising the payment transaction. For 
30 example, the transaction card data may be stored on a magnetic strip of a customer's 
transaction card, such that it can be read quickly when the card is swiped through a 
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magnetic card reader. Alternatively, an electronic chip located on a customer's 
transaction card may be used to store the transaction card data, thereby making the 
transaction card difficult to replicate. Of course, the data may merely be clearly visible 
from the personal item with the naked eye, for example if it were to be displayed on a 
5 personal hand held organiser, in which case the transaction data could simply be read 
and then manually inputted for conversion into an electronic format. 

It is also advantageous if the data concerning the transaction card that is received 
includes the expiry date of the card. This information can then be sent to the acquirer 

10 as part of the authorisation request, guarding against fake cards which have been 
manufactured using valid account details but unknown expiry dates. On receiving an 
authorisation request, an acquirer host terminal can perform an independent check that 
the expiry date received agrees with that stored in its database record for the payment 
transaction card. If the dates do not agree, authorisation of the transaction will not be 

15 given. 

Authorisation may be obtained more quickly in some instances if the establishing step 
is triggered by the occurrence of the receiving step, such that it is carried out at least in 
part concurrently with the presenting and gratuity amount receiving steps. That is to 
20 say that the present invention is not restricted to submitting an authorisation request 
only further to the value of the transaction being determined. 

Merchants will also find it beneficial, for accounting purposes, if receipt data which is 
issued in respect of an authorised transaction is stored in a local database. In addition, 
25 in the event of any future query being made by a customer regarding their transaction, 
the transaction details can be readily recalled. 

It is also advantageous for the method to further comprise creating one or more 
software session instances for the payment transaction requiring on-line authorisation, 
30 the software session instances controlling the receiving, presenting, establishing, 
transmitting, and generating and providing steps for the transaction. By 'on-line 1 it is 



meant requesting authorisation of a payment transaction in real-time whilst the 
customer is waiting. A plurality of software session instances allows transaction card 
details to be received concurrently from more than one source so that initial processing 
can be performed in parallel. In what follows, the terms 'concurrent' or 4 concurrently * 
5 as applied to payment transactions mean payment transactions where at least part of 
the processing of each respective payment transaction is conducted in parallel, namely 
processing of one payment transaction is being carried out at a given moment during 
the processing of another payment transaction. Also where more than one software 
session instance is created per payment transaction, it is possible to break down the 
10 above-mentioned method into modular processes which can be accessed by different 
payment transactions. This is particularly useful where there are shared resources, such 
as a communications link. 

If there are a plurality of payment transactions to be processed and software instances 
15 are created for each payment transaction, then the method may further comprise 
implementing the receiving, presenting, establishing, transmitting, and generating and 
providing steps for the plurality of payment transactions concurrently. In this way, 
details of multiple transactions can be received from a single source without 
authorisation having yet been received for the previous transaction. So, a terminal 
20 operator may swipe several transaction cards through a magnetic card reader, one after 
the other, to trigger the processing of an individual authorisation request for each 
payment that is to be made. By allowing for concurrent processing, the time taken to 
obtain transaction authorisation, and the delay to the customer, can be kept to a 
minimum. 

25 

The present invention' also extends to a payment transaction apparatus for carrying out 
an authorised payment transaction, the apparatus comprising: input means for inputting 
data relating to a customer's transaction card, and data relating to an original amount of 
the payment transaction; presenting means arranged to present the original amount data 
30 to the customer such that a gratuity amount can be determined and in response thereto 
data relating to the gratuity amount can be input via the input means; communication 
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means arranged to establish a link with an acquirer via a telecommunications network 
and to seek online authorisation for the payment transaction by transmitting the 
transaction card data and data relating to a value of the transaction, the transaction 
value comprising the gratuity amount and the original amount; and means for 
5 generating and providing receipt data to the customer, the receipt data confirming 
authorisation of the payment transaction at the transaction value when the transaction 
has been authorised. 

The present invention also provides a system for implementing and authorising a 
10 payment transaction, the system comprising: a payment transaction apparatus as 
described for the second aspect of the present invention; an acquirer apparatus 
arranged to receive a request for an online authorisation of a payment transaction from 
the payment transaction apparatus, to authorise the payment transaction at the 
transaction value and to transmit an authorisation confirmation over the 
15 telecommunications network to the payment transaction apparatus. 

According to another aspect of the present invention there is provided a method of 
authorising concurrent payment transactions with an acquirer, the method comprising: 
establishing a link with the acquirer via a telecommunications network and 

20 transmitting a request for an online authorisation of a first payment transaction using 
received payment transaction data; storing data relating to a second concurrent 
payment transaction in a queue, whilst awaiting the result of the online authorisation of 
the first payment transaction; using the established link to the acquirer to transmit a 
request for online authorisation for the second payment transaction using the payment 

25 transaction data stored in the queue, once the result of the online authorisation request 
for the first payment transaction has been received. 

In this way, when a communications link is established with an acquirer, it may be 
used to obtain authorisation for further transactions requiring authorisation from that 
30 same acquirer rather than being dropped after authorisation has been obtained only for 
a first transaction. Generally, the most time-consuming part in obtaining authorisation 
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for a transaction, particularly where a public switched telephone network is employed, 
is the establishing of a communications link with the relevant acquirer. Hence, the 
speed with which transaction authorisation is obtained can be improved using the 
present invention whenever there may be concurrent transactions for the same 
5 acquirer. 

While the telecommunications link is still established and in use, the storing step 
described above may comprise storing further transaction data in the queue relating to 
other concurrent payment transactions, such that many transactions may be awaiting 
10 authorisation simultaneously. In this way, data relating to a plurality of payment 
transactions can be received, initially processed and stored, prior to a communications 
link with each transaction's acquirer being sought. The greater the number of 
transactions for a given acquirer that are stored, the greater the improvement in 
efficiency that is obtained. 

15 

The method may further comprise: removing data relating to a concurrent payment 
transaction from the queue once an authorisation result for that transaction has been 
received; checking the contents of the queue; and relinquishing the established link 
with the acquirer once there is no further transaction data stored in the queue, after the 

20 result of the online authorisation request for the last transaction has been received. 
Hence, termination of a communications link with an acquirer can be avoided when 
further transaction data has been received requiring authorisation from the same 
acquirer. In other words, before dropping a communications link, a check is always 
made to see if the link could be of immediate further service and should therefore be 

25 maintained. Use of a queue in this way provides an efficient way of handling 
asynchronous authorisation requests which it is desired to process sequentially. 

In order to better process transaction data when authorisation for concurrent 
transactions may be sought from more than one acquirer, the method may further 
30 comprise: considering the acquirers to which the other concurrent payment 
transactions relate, and the storing step may comprise storing only that transaction data 
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in the queue which is directed to the same acquirer as the first payment transaction. In 
addition, transaction data which relates to a different acquirer may be stored in a 
respective queue related to that acquirer for subsequent transmission thereto. Hence, 
by forming separate queues of transactions awaiting authorisation for each different 
5 acquirer (in other words streaming transactions according to their destination 
acquirer), it is possible to group together those payment transactions which can take 
advantage of the present invention, thereby optimising the operation of authorising 
payment transactions to different acquirers. 

10 It is also advantageous for the method to further comprise creating one or more 
software session instances for each payment transaction requiring on-line 
authorisation, the software session instances controlling the establishing, transmitting, 
storing and using steps for that transaction. This is because transaction card details can 
then be received concurrently from more than one source and initial processing can be 

15 performed in parallel. 

Given the capability to process many transaction authorisation requests concurrently, 
the method may further comprise receiving concurrent payment transaction data from a 
plurality of remote terminals. Hence, all transaction authorisation requests can be 
transmitted to a central EFTPOS terminal where they are queued according to their 
destination acquirer, thereby saving costs over having multiple stand-alone EFTPOS 
terminals. If the remote terminals are portable then there is also the added advantage 
that they can be used in close proximity to the customer thereby improving security, 
since the customer's payment transaction card, say, need never leave their sight. 

This aspect of the present invention may also be considered to extend to a method of 
authorising concurrent payment transactions with a first and a second acquirer, the 
method comprising a method of authorising concurrent payment transactions from a 
first acquirer as stated above, wherein the storing step comprises: storing data relating 
to further concurrent payment transactions in the queue and a further queue in 
dependence upon the acquirer to which the payment transaction relates, whilst 
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awaiting the result of the online authorisation for the first payment transaction; the 
method further comprising: relinquishing the established link with the first acquirer 
once there are no further transaction data requests stored in the queue, after the result 
of the online authorisation request for the last transaction to the first acquirer has been 
5 received; and establishing a link with the second acquirer via the telecommunications 
network and transmitting a request for an online authorisation of a further payment 
transaction using received payment transaction data stored in the further queue. 

This aspect of the present invention can also be considered as a method of authorising 
10 concurrent payment transactions with an acquirer, the method comprising: receiving 
date relating to a first and second payment transactions from one or more remote 
terminals; storing the data relating to the second payment transaction in a queue; 
establishing a link with the acquirer via a telecommunications network and 
transmitting a request for online authorisation for the first payment transaction using 
15 the received first payment transaction data; using the established link to the acquirer to 
transmit a request for online authorisation for the second payment transaction, using 
the received second payment transaction data, once the result of the online 
authorisation request for the first transaction has been received; and relinquishing the 
established link with the acquirer after the result of the online authorisation request for 
20 the second transaction has been received. 

Alternatively, this aspect of the present invention can be understood to be a method of 
authorising concurrent payment transactions with an acquirer, the method comprising: 
establishing a link with the acquirer via a telecommunications network; storing data 
25 relating to at least one concurrent payment transaction, required for seeking an online 
authorisation, in a queue; using the established link to the acquirer to sequentially 
transmit requests for and receive results of online authorisations relating to each of the 
concurrent payment transactions until the queue is empty. 

30 The present aspect of the invention also extends to an apparatus for authorising 
concurrent payment transactions with an acquirer, the apparatus comprising: 
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communication means arranged to establishing a link with the acquirer via a 
telecommunications network; transmitting means arranged to transmit a request for an 
online authorisation of a first payment transaction over the link using received 
payment transaction data; and a store for storing data relating to a second and other 
5 concurrent payment transactions in a queue, whilst awaiting the result of the online 
authorisation of the first payment transaction; the transmission means being arranged 
to use the established link to the acquirer to transmit a request for online authorisation 
for the second payment transaction using the payment transaction data stored in the 
queue of the store, once the result of the online authorisation request for the first 
10 payment transaction has been received. 

Advantageously the transmission means may comprise a finite state machine, such that 
account may be taken of different conditions which determine what action is to be 
implemented. Use of a finite state machine in such a transaction processing apparatus 
15 provides an efficient way of handling a plurality of interactive processes which change 
in dependence on external conditions. 

The present aspect of the invention also extends to a system for implementing and 
authorising a payment transaction, the system comprising: a payment transaction 
20 apparatus according to the apparatus described above; an acquirer apparatus arranged 
to receive a request for an online authorisation of a payment transaction from the 
payment transaction apparatus, to authorise the payment transaction at the transaction 
value and to transmit an authorisation confirmation over the telecommunications 
network to the payment transaction apparatus. 

25 

Brief Description of the Drawings 

Methods and apparatus according to presently preferred embodiments of the invention 
for authorising and effecting electronic payment transactions will now be described by 
30 way of example, with reference to the accompanying drawings in which: 
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Figure 1 is a plan view of an authorised payment transaction slip which has been 
produced in accordance with the prior art; 

Figure 2 is a schematic block diagram showing a system for authorising electronic 
5 payment transactions, including a communications system across which authorisation 
for electronic fund transfers is obtained, according to presently described embodiments 
of the invention; 

Figure 3 is a schematic block diagram showing a merchant EFTPOS terminal as 
10 featured in the authorisation system of Figure 2, according to a first embodiment of the 
invention; 

Figure 4 is a flow diagram showing the steps involved in obtaining authorisation for an 
electronic payment transaction, according to the first embodiment of the invention; 

15 

Figures 5 and 6 are plan views of transaction signature slips which have been produced 
in accordance with presently described embodiments of the invention; 

Figures 7 and 8 are plan views of authorised payment transaction receipts which have 
20 been produced in accordance with presently described embodiments of the invention; 

Figure 9 is a schematic block diagram showing a merchant EFTPOS terminal as 
featured in the authorisation system of Figure 2 together with a portable handset, 
according to a second embodiment of the invention; 

25 

Figure 10 is a schematic block diagram showing the merchant EFTPOS terminal of 
Figure 9, and the processing modules created by its EFT processing engine, when in 
communication with five portable handsets; 
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Figure 1 1 is a series of flow diagrams showing the processing performed by a Host 
Connection Manager of Figure 10 in response to various events when it is in an IDLE 
state; 

5 Figures 12 and 12a are a series of flow diagrams showing the processing performed by 
a Host Connection Manager of Figure 10 in response to various events when it is in a 
WAITING CONNECTION state; and 

Figures 13 and 13a are a series of flow diagrams showing the processing performed by 
10 a Host Connection Manager of Figure 10 in response to various events when it is in an 
IN_CONNECTION state. 

Detailed Description of Preferred Embodiments of the Present Invention 

15 With reference to Figure 2, an authorisation system 30 for implementing a first and a 
second embodiment of the present invention will now be described. The authorisation 
system 30 facilitates communication between the parties involved in an electronic 
payment transaction, namely a merchant, a payment cardholder and an acquirer who 
will capture the electronic data concerning the transaction on behalf of the payment 

20 card issuer. It enables the merchant to check whether the acquirer will settle the 
cardholder's bill in due course, particularly when the cardholder also wishes to make a 
gratuity payment using their payment card. The authorisation system 30 shown in 
Figure 2 is comprised of a merchant EFTPOS terminal 32 and a plurality of acquirer 
host terminals 34 (of which only three are shown) which are connected by a central 

25 communications hub, namely an EFT network 36 such as a public telephone network; 
In what follows, the different and specific ways in which the authorisation system 30 is 
used to implement the first and the second presently preferred embodiments of the 
invention are described. 

30 An EFTPOS terminal 32a of the first embodiment is shown in more detail in Figure 3 
and comprises the same elements as those described for the prior art, namely a 
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payment card reader 40, an operator input device 42, an output display screen 44, an 
EFT processing engine 46, a payment transaction database 48, a modem 50 and a 
printer 52. However, the EFTPOS terminal 32a is configured to operate in a different 
manner from that taught by the prior art as is described below. 

5 

The payment card reader 40 is arranged to quickly extract payment card details. Two 
types of payment card are currently available, the first being a magnetic strip variety 
where information has been magnetically encoded onto the card and the second being 
so-called 'smart cards 7 which contain integrated circuitry giving the card limited 

10 processing capabilities. Magnetic cards are usually 'swiped' through a payment card 
reader 40, whilst smart cards are inserted into a reader 40 which accesses the 
information held on their data store. The payment card reader 40 is arranged to read 
both types of card. The operator input device 42 is a keypad which is used to input a 
sale amount and which may also be of assistance if the card reader 40 has difficulty in 

1 5 extracting the payment card details (for example if the card has been damaged in some 
way). The EFT processing engine 46 communicates with a terminal operator via the 
output display screen 44, but this screen could also serve as an operator input device 
42 if it was arranged to be touch sensitive. Hence, the payment card reader 40, the 
operator input device 42 and the display screen 44 behave in essentially the same 

20 manner as in the prior art systems. 

However, the remaining elements are arranged to perform slightly different functions 
to those required by existing processing systems, in that they enable authorisation to be 
obtained in real-time for a total amount that the cardholder wishes to pay. This is 
25 achieved by providing the cardholder with the opportunity to finalise their bill before 
contacting the relevant acquirer host terminal 34 for authorisation. 

An authorisation process 60 for determining the full amount to be paid and obtaining 
authorisation for that amount will now be described with reference to Figure 4. The 
30 authorisation process 60 breaks down into three key stages: (1) inputting of payment 
card details and sale information; (2) printing off of a signature slip which is then 
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completed by the cardholder; and (3) obtaining transaction authorisation from an 
acquirer host terminal. 

The first stage is initiated at step 62 by inputting the payment card details into the 
5 EFTPOS terminal 32a using the payment card reader 40. These details are sent to the 
EFT processing engine 46 at step 64, which then stores them in the payment 
transaction database 48. The EFT processing engine 46 issues a message to the output 
display screen 44 at step 66, prompting the terminal operator to enter a sale amount 
using the operator input device 42 which is subsequently written to the payment 
10 transaction database 48. The sale amount, together with the payment card details input 
at step 62, are sent by the EFT processing engine 46 to the printer 52. This instigates 
the second stage of the authorisation process 60, whereby a transaction signature slip, 
which is to be retained by the merchant, is printed off from the EFTPOS terminal and 
presented to the cardholder. 

15 

The information to be displayed on each signature slip is printed off in two parts. The 
first part comprises the payment card details and the sale amount and is printed at step 
68 in the authorisation process 60, producing a 'small ticket'. The information printed 
for the second part depends upon the mode of terminal operation pre-selected by the 
20 terminal operator, as considered at step 70. 

The two modes of operation are 'gratuity' and 'non-gratuity'. Examples of the 
different types of signature slip 100 and 120 which are produced by these modes are 
shown in Figures 5 and 6, respectively. If the EFTPOS terminal 32a is operating in 

25 gratuity mode, then the EFT processing engine 46 instructs the printer 52 at step 72 to 
print off lines which permit a gratuity amount 102 and a total amount 104 to be 
entered, as shown in Figure 5. A signature field line 106 is also printed, followed by 
additional information concerning the transaction 108. Under the non-gratuity mode of 
operation, the EFT processing engine 46 instructs the printer 52 at step 74 to restate 

30 the sale amount as the total amount 122, to print off a signature field line 124 and to 
print out the same additional information 108 regarding the transaction as included at 
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the end of the gratuity-mode signature slip 100, as shown in Figure 6. This second 
mode of operation is required for situations where it is not appropriate to suggest 
gratuity payments. For example, if a cardholder correctly complains that they have 
been overcharged on their itemised bill, the merchant may dictate that the cardholder 
5 should not in any way be induced to make a gratuity payment. Alternatively, the 
merchant may offer other services which do not attract gratuity payments - for example 
a restaurant which also operates a take-away facility - in which case merchant staff can 
present cardholders with transaction signature slips which are appropriate for the 
service they have used. 

10 

The- signature slips of Figures 5 and 6 are very similar to the authorised transaction slip 
10 of the prior art, shown in Figure 1 . The key difference, however, is that the sub-total 
amounts on the signature slips 100 and 120 have not been authorised by an acquirer 
host terminal 34. The authorisation code 23, present in Figure 1, is therefore absent 
15 from these slips. Another difference can be seen between the additional information 
108 and 24 that is provided about the transaction - an internal reference number for 
recalling the transaction for completion is not quoted in the additional data 108, as 
contact has not yet been made with the acquirer host terminal 34; instead the signature 
slip is referenced by an internal slip number 110. 

20 

The cardholder goes on to complete whichever signature slip they are presented with at 
step 76 or step 78, respectively, of the authorisation process 60. In the case of the 
signature slip 100, the cardholder can specify the total amount 104 that they wish to 
pay prior to authorisation being sought from their acquirer. The signature provided by 
25 the cardholder is compared to the one displayed on the payment card at step 80 for 
both modes of operation. 

On returning to the EFTPOS terminal 62 with the completed signature slip, the 
terminal operator accesses the payment transaction details from the payment 
30 transaction database 48. For both modes of operation at step 82 the EFT processing 
engine 46 prompts the terminal operator, via the output display screen 44, to confirm 
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whether the signatures matched. The terminal operator answers using the operator 
input device 42. If the signatures are judged not to have matched, in either state of 
operation, then at step 84 the EFT processing engine 46 deletes the transaction details 
from the payment transaction database 48 and the authorisation process 60 is ended 
prematurely. 

Alternatively, if the cardholder's signature is judged to be valid then the EFT 
processing engine 46 begins the third stage of the authorisation process 60, whereby 
authorisation for the payment transaction is sought from the relevant acquirer host 
terminal 34. When the EFTPOS terminal 32a is in gratuity mode, the EFT processing 
engine 46 prompts the terminal operator at step 86 to enter the total amount 104 
indicated by the cardholder on the signature slip 100. The EFT processing engine 46 
then accesses the transaction details in the payment transaction database 48 and 
overwrites the stored sale amount with the total amount 104. 

The processing for the two different modes of operation then converges at step 88, 
when the EFT processing engine 46 obtains the transaction details from the payment 
transaction database 48. This information, together with the merchant ID, is sent to the 
appropriate acquirer host terminal 34 as an authorisation request. As a security 
measure, a message authentication block is added to the end of the data, such that if 
the data is tampered with or is inadvertently distorted during transmission, it will be 
evident to both the acquirer host terminal and the payment terminal (this is a well 
known technique). The information read from the payment card at step 62 will have 
included the international identification number, namely the leading digits of the card's 
primary account number, which is used to identify the card issuer in accordance with 
ISO standards; this number determines which acquirer host terminal 34 is contacted. 

Returning to Figure 2, the EFT processing engine 46 accesses the EFT networks 36 via 
its modem 50 and establishes a communications link 38 between the EFTPOS terminal 
32a and the appropriate acquirer host terminal 34 (in Figure 2 this is ACQUIRER 1). 
The information is then transmitted in accordance with the local standard for enabling 
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on-line authorisation and exchange of transaction data between the merchant and 
acquirer host terminals at the time of the transaction (in the UK this standard is 
APACS 40). 

5 On receiving the authorisation request, the acquirer host terminal 34 authenticates it 
and accesses the cardholder's account to check the validity of the payment card and to 
determine if sufficient funds are available. An authorisation response, containing an 
authorisation code which indicates whether the transaction is accepted or rejected, is 
then generated by the acquirer host terminal 34 and transmitted back to the EFT 
10 processing engine 46 via the communications link 38. 
». 

Meanwhile in the authorisation process 60 of Figure 4, at step 90, the EFT processing 
engine 46 has been awaiting a response to its authorisation request. On receiving a 
response, it closes the communications link 38, authenticates the response, extracts the 

15 authorisation code and prompts the printer 52 to print off two authorised transaction 
receipts: one for the merchant as shown in Figure 7 and one for the cardholder as 
shown in Figure 8. At step 92 the merchant receipt 130, or 'full merchant ticket', is 
generated and is clearly marked as a duplicate copy. This receipt confirms the amount 
1 32 to be paid in the payment transaction, as indicated previously in either the total 

20 field 104 (gratuity mode) or the total field 122 (non-gratuity mode), and quotes the 
authorisation code 134 under which the acquirer host terminal 34 has authorised 
payment. 

A copy of the authorised transaction receipt 140 which is to be retained by the 
25 cardholder is printed at step 94. 

Finally, at step 96 of the authorisation process 60, the signature slip 100 or 120 which 
has been completed by the cardholder is attached to the merchant receipt 130. This is 
retained by the merchant for future reference. 

30 
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Following the conclusion of the authorisation process 60, the cardholder can leave the 
merchant premises knowing that authorisation has been given for the total amount of 
the payment transaction and all processing to be performed at the merchant premises 
has been completed. 

5 

The second presently preferred embodiment of the invention will now be described 
with reference to Figures 9 and 10. This embodiment demonstrates how the invention 
may be implemented using a EFTPOS 'base' terminal which communicates with a 
plurality (five in this embodiment) of portable handsets by means of radio 

10 communication. The handsets have a range of up to 100 metres and can be brought to 
the 'cardholder, so a cardholder need never lose sight of their payment card during a 
payment transaction, providing a high level of security. However, prior to the present 
invention, it has been necessary to establish a communications link between an 
EFTPOS 'base* terminal and the relevant acquirer host terminal each time 

15 authorisation is sought. Establishing a communications link is the most time- 
consuming part of a payment transaction, with the time taken for data transmission 
being so short as to be almost inconsequential. Therefore, in addition to demonstrating 
how the security of payment transactions, made via portable handsets and an EFTPOS 
'base' terminal, can be improved, the following embodiment also shows how the 

20 processing time for such transactions may be reduced. 

Figure 9 shows a merchant EFTPOS 'base' terminal 32b accompanied by a single 
portable handset 150, although it is to be appreciated that five handsets 150 are 
supported by the terminal at any one time. The EFTPOS 'base' terminal 32b is suitable 
for use in the authorisation system 30 shown in Figure 2. However, it differs from the 
previously described EFTPOS terminal 32a of Figure 3, in that it is comprised only of 
an EFT processing engine 152 and a payment transaction database 154, together with a 
radio transceiver 156. The remaining elements found in the EFTPOS terminal 32a are 
housed in the portable handset 150, namely being a payment card reader 158, an 
operator input device 160, a printer 162 and an output display screen 164. The portable 
handset 150 additionally features a controller 165, to which all of the other elements 
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are connected and which controls their ftinctionality (in the first embodiment this 
control processing was performed directly by the EFT processing engine 46), and a 
radio transceiver 166, enabling it to communicate with the EFTPOS 'base' terminal 
32b via a radio communications link 168. 

5 

The steps required for effecting payment via a portable handset 1 50 are similar to those 
outlined in the authorisation process 60 of Figure 4, for the first embodiment, and so 
only the differences are described in detail hereafter. Payment card details and a sale 
amount are entered into a portable handset 150 rather than the EFTPOS terminal itself, 

10 with the handset being held in close proximity to the payment cardholder. After 
communicating with the EFTPOS 'base' terminal 32b, the portable handset 150 
produces a transaction signature slip as shown in Figure 5 or Figure 6, but with two 
additional data fields included in the additional information 108. The first data field 
relates to an identification number for the handset and the second to an internal count 

1 5 of the transactions processed by the handset. The cardholder completes the transaction 
signature slip, indicating the total amount that is to be paid. The operator of the 
portable handset 150 then enters the total amount into the portable handset 150, using 
the operator input device 160. This information is then transmitted to the EFT 
processing engine 46 at the EFTPOS 'base' terminal 32b. Only at this stage, when the 

20 total amount to be paid has been determined, is authorisation sought for the payment 
transaction. The authorised transaction receipts that are produced are similar to those 
shown in Figures 7 and 8, but they again contain the two additional data fields 
mentioned above, plus a further data field for an internal count of the authorisations 
obtained. 

25 

A key difference between the two embodiments occurs at step 88 in the authorisation 
process 60 of Figure 4, when the transaction details are sent to the EFT processing 
engine 152. Unlike the first embodiment, where payment transactions are processed 
one at a time, the EFT processing engine 152 can process multiple sets of payment 
30 transaction details simultaneously. Each set of details received is streamed according 
to the acquirer host terminal 34 from which authorisation must be sought; the details 
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are then placed in a queue until a communications link 38 to that acquirer host 
terminal 34 becomes available. As in the first embodiment, the EFTPOS 'base' 
terminal 32b is only in communication with a single acquirer host terminal 34 at any 
one time. However, in the second embodiment requests for authorisation are 
5 effectively strung together, so that all queued transaction details for that acquirer host 
terminal 34 are sent prior to the communications link 38 being closed down. By 
stringing transaction authorisation requests together, delays associated with having to 
repeatedly establish communications links 38 can be avoided. 

10 In order to process multiple sets of payment transaction details, the EFT processing 
engine 152 employs four different types of processing module: Sale Manager, EFT 
Server, Host Connection Manager and Host Session Manager. Figure 10 shows an 
EFTPOS 'base' terminal 32b in communication with five portable handsets 150; it 
also shows various instances of the processing modules which have been created by 

15 the EFT processing engine 152. The key functionality of each module/instance is 
briefly summarised below. 

Whenever the EFT processing engine 152 receives payment card details from a 
portable handset 150 (at step 64 in Figure 4), it creates an instance 170 of the Sale 
20 Manager module. This module is concerned with the processing of payment card and 
transaction data and with storing information in the payment transaction database 154. 
In addition, each Sale Manager instance 1 70 oversees communication with the portable 
handset 150 with which it is associated, such as requesting a sale amount and issuing 
instructions to the handset's on-board printer 162. 

25 

Each Sale Manager instance 170, in turn, creates an instance 172 of an EFT Server 
module. EFT Server instances 172 request connection to a communications link 38 
with the host terminal 34 of the acquirer for that particular stream; they also perform 
any authentication tasks that are required to support the APACS 40 protocol. 

30 
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Each request for connection is sent to an appropriate instance 174 of a Host 
Connection Manager module. Each instance 174 of a Host Connection Manager 
module is a finite state machine, such that the instance may be in one of several 
predetermined finite states. Only one instance of this module exists per stream i.e. per 
5 acquirer host terminal 34. When the EFT processing engine 152 receives a set of . 
payment card details, it notes the acquirer host terminal 34 from which authorisation 
must be sought and creates an instance 174 of a Host Connection Manager module if 
one does not already exist. Each Host Connection Manager instance 174 maintains a 
queue of connection requests received from its associated EFT Server instances 172 
10 and decides to which of these instances 172 the communications link 38 should be 
allocated. 

Management of the communications link 38, itself, is handled by an instance 176 of a 
Host Session Manager module. This module is concerned with initiating and 
15 terminating communications links 38 in compliance with national standards. The EFT 
processing engine 152 creates an instance 176 of a Host Session Manager module for 
every Host Connection Manager instance 174. As can be seen from Figure 10, each 
Host Session Manager instance 176 contacts its designated acquirer host terminal 34 
through a shared communications resource, namely a modem 178. 

20 

Further to payment transaction details being streamed by the EFT processing engine 
152, the reduction in payment transaction processing time is achieved by the queuing 
and stringing of these details as performed by instances 174 of the Host Connection 
Manager module. The processing conducted by the Host Connection Manager 
25 instances 174 will now be described. In what follows, instances of the EFT Server 
module, the Host Connection module and the Host Session Manager module will be 
referred to as EFT Servers 172, Host Connection Managers 174 and Host Session 
Managers 176, respectively. 

30 When an EFT Server 1 72 terminates its connection with a communications link 38, the 
associated Host Connection Manager 174 allocates the link to the next EFT Server 172 

25 



awaiting connection. Alternatively, if its queue for connection requests is empty, the 
Host Connection Manager 174 instructs the Host Session Manager 176 to terminate 
the communications link 38. Another Host Session Manager 176 can then access the 
modem 178 and establish a new communications link 38 with a different acquirer host 
5 terminal 34. This processing is explained in more detail below. 

An EFT Server 172 can send the following messages to its Host Connection Manager 
174: 'CONNECT', 'TRANSMIT' and 'DISCONNECT'. The 'CONNECT' message is 
sent after the EFT processing engine 152 has received both the payment card details 

10 and the total amount to be paid from a portable handset 150; this message informs the 
Host Connection manager 174 that the EFT Server 172 requires connection with a 
communications link 38 to the appropriate acquirer host terminal 34. The 
'TRANSMIT' message is sent after the Host Connection Manager 174 informs the 
EFT Server 172 that it is connected to the communications link 38 and causes the 

15 payment transaction details to be transmitted to the acquirer host terminal 34. Finally, 
the 'DISCONNECT' message is issued when the EFT Server 172 has received 
authorisation for the payment transaction from the acquirer host terminal 34, or when 
the portable handset operator has terminated the transaction prematurely. 

20 A Host Connection Manager 1 74, which as mentioned earlier is a finite state machine, 
can be in one of three states when it receives these messages: IDLE, 
WAITING_CONNECTION or IN_CONNECTION. The detection of each message 
received is referred to as an 'event'. The response of a Host Connection Manager 174 
to an event is dependent upon what state it is in when the message is received. The 

25 various processes performed by a Host Connection Manager 174 in response to 
messages received in each of the IDLE, WAITING_CONNECTION and 
IN_CONNECTION states are shown, respectively, in Figures 11,12 and 12a, and 13 
and 13a. 

30 Host Connection Managers 174 are in the IDLE state when not in, or attempting to 
make, connection with an acquirer host terminal 34. Hence, this represents the 
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initialised state of a Manager when its queue for connection requests is empty. A Host 
Connection Manager 174 is also placed in this state when repeated attempts to 
establish a communications link 38 have failed as a result of network communication 
problems. The processing performed by a Host Connection Manager 174 in the IDLE 
5 state will now be discussed with reference to Figure 1 1 . 

When a Host Connection Manager 174 receives a * CONNECT' message from one of 
its EFT Servers 172, it executes a 'CONNECT' response process 190. After detecting 
the message at step 192, the Host Connection Manager 174 updates its state to 
10 4 WAITING_CONNECTION' at step 194; it then instructs the Host Session Manager 
176, at step 196, to establish a communications link 38 with the designated acquirer 
host terminal 34. The process 190 is terminated at step 198, when all of the necessaiy 
processing to be performed by the Host Connection Manager 174 has been completed. 

15 Any other events detected by a Host Connection Manager 174 in the IDLE state are 
dealt with by an error handling process 200. Any unexpected message is detected at 
step 202 and sent to an instance of an error recovery module at step 204; the instance 
then deals with the event in a predetermined manner. 

20 If a Host Connection Manager 174 is already in the WAITING_CONNECTION state 
when it receives a * CONNECT' message from one of its EFT Servers 172, it executes 
a 'CONNECT' response process 210 as shown in Figure 12. The Host Connection 
Manager 174 checks at step 212 to see if a communications link 38, or 'Host 
Connection', is currently assigned to one of its EFT Servers 172. If this is not the case 

25 then the Host Connection Manager 174 allocates the link to the requesting EFT Server 
172 directly, at step 214, by setting it as the 'current EFT Server'. However, the 
communications link 38 has not yet been instigated and so at step 216 the Host 
Connection Manager 174 instructs the Host Session Manager 176 to commence the 
connection process. 

30 
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If the communications link 38 has already been allocated to a particular EFT Server 
172 then the Host Connection Manager 174 checks to see whether it has received a 
repeat 'CONNECT' message from the same EFT Server 172 (a message may be sent 
periodically from a requesting EFT Server 172 until confirmation of connection is 
5 received). The Host Connection Manager 174 performs this check at step 218 and, if 
necessary, repeats its earlier instruction to the Host Session Manager 176 at step 216. 
Otherwise, the request for connection to a communications link 38, which has already 
been allocated to another EFT Server 172, is placed into a queue by the Host 
Connection Manager 174 at step 220. 

10 

Further to instructing its Host Session Manager 176 at step 216, a Host Connection 
Manager 174 may receive one of the following messages in reply: 'DELAY', 
'CONNECTED' or 'CONNECTION FAILED'. When a Host Connection Manager 
174 is informed of a delay in the connection process, it executes a 'DELAY' response 

15 process 230 - passing the message on to all of its associated EFT Servers 172 at steps 
232 and 234. When the Host Connection Manager 174 receives a message 
'CONNECTED', informing it that connection with the acquirer host terminal 34 has 
been successfully achieved, it responds via the 'CONNECTED' response process 240. 
In this process, the Host Connection Manager 174 updates its state to 

20 'INCONNECTION' at step 242, before notifying the EFT Server 172 to which the 
communications link 38 has been allocated of its successful connection to the link. 

If attempts by the Host Session Manager 176 to create a communications link 38 fail, 
then the Host Connection Manager 176 responds via the appropriate branch of process 
25 250. Further to receiving a message 'CONNECTION FAILED' at step 252a, the Host 
Connection Manager 174 resets its state to 'IDLE' at step 254 and then, at step 256, 
forwards the message to the EFT Server 172 to which the link was allocated. 

A 'DISCONNECT' response process 260 is executed by a Host Connection Manager 
30 174 when it detects a 'DISCONNECT' message from one of its EFT Servers 172. The 
Host Connection Manager 1 74 checks, at step 262, to see whether the communications 
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link 38 has been allocated to the EFT Server 172 which issued the message. If this is 
not the case, then the Host Connection Manager 174 makes a further check, at step 
264, to see if it has received a request from the EFT Server 172 for connection to the 
communications link 38. Any request that has been made is removed from the request 

5 queue by the Host Connection Manager 174 at step 266. Alternatively, if a spurious 
'DISCONNECT 5 message has been received which does not have a counterpart in the 
queue for connection requests, then the error handling process 200 of Figure 1 1 is 
employed (not shown in process 260). However, if following step 262, it is found that 
the communications link 38 is allocated to the EFT Server 172 which sent the 

10 'DISCONNECT' message, then the Host Connection Manager 1 74 checks to see if the 
allocation can be transferred to another EFT Server 172 which has requested 
connection. It does this by executing, at step 268 in process 260, a Transfer Host 
Connection process 270 which is now described in detail with regard to Figure 12a. 

15 The Transfer Host Connection process 270 begins by cancelling allocation of the 
communications link 38 at step 272, when the Host Connection Manager 174 resets 
the 'current EFT Server* variable to 'NONE'. The Host Connection Manager 174 then 
checks its queue of connection requests at step 274. If the queue is empty then the Host 
Connection Manager 174 resets its state to IDLE at step 276 and instructs the Host 

20 Session Manager 176 to terminate the communications link 38 at step 278. 
Alternatively, if farther EFT Servers 172 are awaiting connection to the 
communications link 38, then the Host Connection Manager 174 edits the queue as 
indicated at step 280. It identifies the oldest request, removes that request from the 
queue and sets the EFT Server 172 which made that request as the 'current EFT 

25 Server*. Accordingly, there is no need to terminate the existing attempt at 
communication with the acquirer host terminal 34. 

Finally, a Host Connection Manager 174 in the WAITING_CONNECTION state will 
respond via process 250 of Figure 12 if it receives a message 'DISCONNECTED' 
30 from the Host Session Manager 176 at step 252b. 
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Any other events that are detected by a Host Connection Manager 174 when it is in the 
WAITING_CONNECTION state are handled by an error handling process 200 as 
shown in Figure 1 1 . 

5 Once a Host Session Manager 176 has established a communications link 38 with an 
acquirer host terminal 34, its Host Connection Manager 174 will be in the 
IN_CONNECTION state. The responses of a Host Connection Manager 174 in this 
state are those set out in Figures 13 and 13a. 

10 When a Host Connection Manager 174 receives a 'CONNECT' message, it executes 
the .'CONNECT' response process 290. This process is identical to the 'CONNECT' 
response process 210 of Figure 12, except that the instruction to commence connection 
at step 216 in the latter process 210 is omitted in the present process 290 on account of 
the present state of the Host Connection Manager 174. 

15 

If a Host Connection Manager 174 receives a message from its Host Session Manager 
176, informing it that the communications link 38 is subject to a 'DELAY', then it 
executes the 'DELAY' response process 300. Again, this process 300 is identical to 
the 'DELAY' response process 230 shown in Figure 12 conducted under the 
20 WAITING_CONNECTION state, except for the inclusion of an additional step 302 
whereby the state of the Host Connection Manager 174 is reverted to 
WAITING_CONNECTION. 

Further to an EFT Server 172 receiving a 'CONNECTED' message as a result of 
25 process 240, it sends a 'TRANSMIT' message to its Host Connection Manager 174. 
causing the Host Connection Manager 174 to execute a 'TRANSMIT' response 
process 310. After receiving the message at step 312, the Host Connection Manager 
174 instructs the Host Session Manager 176 to send the payment transaction data as an 
authorisation request to the acquirer host terminal 34 at step 314. 

30 
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When a Host Session Manager 176 receives a response to an authorisation request 
from its designated acquirer host terminal 34, it sends a message 4 DATA RECEIVED' 
to its Host Connection Manager 174, causing the execution of a 'DATA RECEIVED' 
response process 320. The message is forwarded to the 'current 5 EFT Server 172 at 
5 step 322, indicating the conclusion of communication with the acquirer host terminal 
34 for that particular the payment transaction. 

Accordingly, the EFT Server 172 then sends a 'DISCONNECT' message which 
triggers the 'DISCONNECT' response process 330. This process is identical to the 

10 'DISCONNECT' response process 260 outlined in Figure 12. However, the Transfer 
Host Connection process 340 shown in detail in Figure 13a and called at step 332 
differs from the equivalent Transfer Host Connection process 270 which is executed 
under the WAITING_CONNECTION state. An additional step 342 appears in process 
340, whereby when the communications link 38 has been allocated to a new EFT 

15 Server 172, the Host Connection Manager 174 also sends a message to that EFT 
Server 172 informing it that it is 'CONNECTED'. The newly connected EFT Server 
172 may then send a 'TRANSMIT' message back to its Host Connection Manager 
1 74, thereby leading to stringing of payment transaction authorisation requests. 

20 Further to instructing its Host Session Manager 176 to drop a communications link 38 
in the event of an empty EFT Server queue, a Host Session Manager 174 will receive a 
'DISCONNECTED' message when the link has been terminated. It then executes a 
response process 350, also shown in Figure 13a, which is identical to the process 250 
of Figure 12, such that the Host Connection Manager 174 responds in the same manner 

25 as that described previously when it is informed that a connection attempt has failed. 

As for the previous states, the detection of any other message causes an error handling 
process 200 to be invoked, as shown in Figure 1 1 . 

30 By processing payment transaction details in this way, namely by streaming them, 
queuing them and then stringing them together, the EFT processing engine 152 can 
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help to reduce the time taken to obtain authorisation. Cardholders are therefore less 
likely to suffer an onerous delay and can proceed about their business quickly. 

Having described particular preferred embodiments of the present invention, it is to be 
5 appreciated that the embodiments in question are exemplary only, and that variations 
and modifications, such as those that will occur to those possessed of the appropriate 
knowledge and skills, may be made without departure from the spirit and scope of the 
invention as set forth in the appended claims. For example, rather than storing 
information which can be used to invoke payment from an issuer on a plastic payment 

10 card, the information could be held on another device which is not solely dedicated to 
that* purpose. Details of a person's payment account could be stored electronically on 
their mobile phone or personal electronic organiser, or, say, a key ring fob which has 
been configured to store electronic data. The details could then be transferred 
wirelessly, say, to a merchant's portable handset by means of the Bluetooth 

15 communications protocol or, alternatively, some physical connection could be 
employed permitting the details to be downloaded from the customer's portable 
handheld electronic device. Similarly, the card details could be conveyed verbally to 
the operator and keyed into the terminal (this approach would be less secure because of 
the lack of local security checks). In this way, the payment card reader used in the two 

20 embodiments described above would effectively be redundant. 

Although a customer is generally informed of an outstanding amount that is to be paid 
prior to their deciding on whether to make a gratuity payment, the way in which the 
outstanding amount is communicated need not be restricted to presenting the customer 

25 with a paper bill. The outstanding amount could merely be communicated verbally, or 
alternatively it could be presented to the customer via a display screen on board a 
portable handset, for example. The customer could then either (1) indicate a gratuity 
that they wished to pay in addition to the outstanding amount or (2) indicate a gratuity 
and a confirmation of the total amount that is to be paid or (3) only indicate a total 

30 amount that is to be paid. Rather than providing the customer with a transaction 
signature slip, indication by the customer could take the form of, say, entering the 
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amount(s) into a personal portable electronic device, the device being arranged to 
transmit the entered information wirelessly to the merchant's portable handset; in this 
way the customer could keep an up-to-date log of the expenditure from their payment 
account on their portable electronic device. Alternatively, the customer could key the 
5 amount(s) that they wish to pay directly into a merchant portable handset or they could 
just communicate verbally the amount(s) to the portable handset operator who would 
then enter the information manually into the handset on their behalf. 

A transaction signature slip could, of course, take a virtual form if a merchant's 
10 portable handset is fitted with a touch screen display, permitting the customer to 
indicate a gratuity and/or final amount that is to be paid and sign their signature 
directly onto the display screen. A digital recording of the signature could then be 
stored electronically and submitted to the acquirer along with the rest of the transaction 
information. In addition, where portable handsets are used, rather than relying on 
15 signature verification to check that a person offering a payment card for settlement is 
in fact the authorised cardholder, a system employing biometrics could be introduced. 
A digital image of the person's fingerprint, say, could be transmitted for verification to 
the acquirer host terminal along with the payment transaction details. Similarly, a 
cardholder could be required to enter a PIN (personal identification number) prior to 
20 the transaction details being sent for authorisation. 

When communicating with an acquirer host terminal, in addition to conventional 
transmissions across public switched telephone networks, other types of 
communications such as those supported by the ISDN standard can be used. 

25 Alternatively, dedicated leased-lines may be employed to achieve the fastest rates of 
data transmission. Verbal communication with an acquirer may also be resorted to in 
the event of any network communication problems. Similarly, communication between 
portable handsets and an EFTPOST 'base' terminal need not be restricted to radio 
waves - communication could also be readily achieved via other mobile, wireless or 

30 digital electronic cordless telephony systems. Another variation would be to provide a 
separate communications resource for every acquirer host terminal from which the 
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merchant is willing to accept payment - so in the second embodiment described above, 
for example, a separate telephone line would need to be installed for each acquirer host 
terminal. Also, attempts to contact the acquirer host terminal can occur at any time 
after the details of a payment card (or other means) have been extracted, rather than 
5 conforming with conventional methods and waiting explicitly until a local security 
check (such as signature verification) has been performed. 

A system of an EFTPOS 'base' terminal and portable handsets could also be adapted 
such that if the power on one handset runs out whilst it is processing a payment 
10 transaction, the payment transaction can be picked up by another handset via 
communication with the base terminal. 

In addition to what is described above for the second embodiment, it is also possible to 
enter the details of several payment cards into a portable handset consecutively. For 

15 example, if a group of six people in a restaurant decides to split a bill equally and each 
person wishes to pay their share using their own payment card, then a portable handset 
operator could swipe the six cards through one after the other, so that six instances of a 
Sale Manager module are created by the EFT processing engine. However, when 
issuing the resultant transaction signature slips back to the group for completion and 

20 signature, the handset operator would need to exercise care in marrying up the correct 
slip with the correct person. Similarly, in the first embodiment, the details of several 
payment cards could be entered into the EFTPOS terminal one after the other and 
processed concurrently, without waiting for the transaction signature slips to be printed 
off. 

25 

Receipts need not only take the form of paper slips - the information could be 
downloaded digitally from the merchant to the customer's own portable handheld 
electronic device. 

30 The merchant's copy of the authorisation slip (see Figure 7), need not be printed while 
the transaction is performed in front of the customer. Instead, this information can be 
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printed as part of a report, giving details of all transactions which were authorised over 
a specified time period. The internal slip number 1 10 on the transaction signature slip 
(see Figure 5) can be used to reference the authorisation code for the transaction as and 
when necessary. 

5 

Finally, an authorisation authority may introduce a minimum transaction amount, or 
so-called 'floor limit', which needs to be exceeded in order to warrant an authorisation. 
Typically, transactions less than £15 may be deemed to be of such small value as to 
make the associated risk of fraud insufficient to warrant an on-line authorisation. The 

10 point of using such a threshold is to reduce the number of authorisation requests being 
generated at any time to a manageable number. In this case, an EFT processing engine 
can be adapted to make an electronic decision as to whether authorisation need be 
sought in accordance with the merchant's floor limit specification. The processing of 
transaction data is further improved by allowing those transactions with values which 

15 fall below the floor limit to be authorised immediately without waiting for any online 
transactions to be first authorised. 
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Claims: 



1 . A method of authorising a payment transaction, the method comprising: 
receiving data relating to a customer's transaction card, and data relating to an 

5 original amount of the payment transaction; 

presenting the original amount data to the customer such that a gratuity amount can 
be determined and in response thereto receiving data relating to the gratuity amount; 

establishing a link with an acquirer via a telecommunications network and seeking 
online authorisation for the payment transaction by transmitting the transaction card data 
1 0 and data relating to a value of the transaction, the transaction value comprising the gratuity 
amount and the original amount; and 

generating and providing receipt data to the customer, the receipt data confirming 
authorisation of the payment transaction at the transaction value when the transaction has 
been authorised. 

15 

2. A method according to Claim 1, wherein the customer transaction card data is 
stored on a personal item of said customer, and the method further comprises obtaining the 
transaction card data from the personal item for the purposes of authorising the payment 
transaction. 

20 

3. A method according to Claim 2, wherein the obtaining step comprises reading 
data stored on a magnetic strip of a customer's transaction card. 

4. A method according to Claim 2, wherein the obtaining step comprises reading 
25 data stored on an electronic chip of a customer's transaction card. 

5. A method according to Claim 2, wherein the obtaining step comprises using a data 
input device, such as a keyboard, for manually inputting data displayed on the personal 
item and converting it into an electronic format. 

30 
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6. A method according to any preceding claim, wherein the presenting step comprises 
outputting data in a humanly readable format. 

7. A method according to Claim 6, wherein the outputting step further comprises 
printing at least the original amount data onto a slip. 

8. A method according to Claim 6, wherein the outputting step further comprises 
displaying at least the original amount data on a display screen. 

9. A method according to any preceding claim, further comprising obtaining further 
information from the customer regarding the transaction value. 

10. A method according to Claim 9, wherein the further information obtained is the 
gratuity amount and a transaction amount, the method further comprising checking that the 
transaction amount is the sum of the original amount and the gratuity amount and 
subsequently using the transaction amount as the transaction value. 

11. A method according to Claim 9, wherein the further information obtained is the 
gratuity amount, the method further comprising determining the transaction value by 
adding the gratuity amount to the original amount. 

12. A method according to Claim 9, wherein the further information obtained is a 
transaction amount, the method further comprising determining the gratuity amount by 
subtracting the original amount from the transaction amount. 

13. A method according to any preceding claim, wherein the receiving step comprises 
receiving data relating to the expiry date of the customer's transaction data card for 
transmission to the acquirer. 
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14. A method according to any preceding claim, wherein the establishing step is 
triggered by the occurrence of the receiving step and is carried out at least in part 
concurrently with the presenting and gratuity amount data receiving steps. 

5 15. A method according to any preceding claim, wherein the establishing and 
transmitting steps are implemented using the APACS 40 standard format. 

16. A method according to any preceding claim, wherein the generating and providing 
step comprises outputting compiled receipt data in a humanly readable format. 

10 

17. * A method according to Claim 17, wherein the receipt data outputting step further 
comprises printing the authorised transaction value data onto a slip. 

18. A method according to Claim 17, wherein the receipt data outputting step further 
1 5 comprises displaying the authorised transaction value data on a display screen. 

19. A method according to any of Claims 17 to 19, wherein the receipt data outputting 
step further comprises outputting an authorisation code received from the acquirer 
confirming the authorisation of the transaction. 

20 

20. A method according to any preceding claim, further comprising storing the receipt 
data in respect of each payment transaction in a local database for accounting purposes. 

21. A method according to any preceding claim, further comprising creating one or 
25 more software session instances for the payment transaction requiring on-line 

authorisation, the software session instances controlling the receiving, presenting, 
establishing, transmitting, and generating and providing steps for the transaction. 

22. A method according to Claim 22, wherein there are a plurality of payment 
30 transactions to be processed and software session instances are created for each payment 

transaction, the method further comprising implementing the receiving, presenting, 
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establishing, transmitting, and generating and providing steps for the plurality of payment 
transactions concurrently. 

23. A payment transaction apparatus for carrying out an authorised payment 
5 transaction, the apparatus comprising: . 

input means for inputting data relating to a customer's transaction card, and data 
relating to an original amount of the payment transaction; 

presenting means arranged to present the original amount data to the customer such 
that a gratuity amount can be determined and in response thereto data relating to the 
1 0 gratuity amount can be input via the input means; 

communication means arranged to establish a link with an acquirer via a 
telecommunications network and to seek online authorisation for the payment transaction 
by transmitting the transaction card data and data relating to a value of the transaction, the 
transaction value comprising the gratuity amount and the original amount; and 
15 means for generating and providing receipt data to the customer, the receipt data 

confirming authorisation of the payment transaction at the transaction value when the 
transaction has been authorised. 

24. A system for implementing and authorising a payment transaction, the system 
20 comprising: 

a payment transaction apparatus according to Claim 24; 

an acquirer apparatus arranged to receive a request for an online authorisation of a 
payment transaction from the payment transaction apparatus, to authorise the payment 
transaction at the transaction value and to transmit an authorisation confirmation over the 
25 telecommunications network to the payment transaction apparatus. 

25. A method of authorising concurrent payment transactions with an acquirer, the 
method comprising: 

establishing a link with the acquirer via a telecommunications network and 
30 transmitting a request for an online authorisation of a first payment transaction using 
received payment transaction data; 
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storing data relating to a second concurrent payment transaction in a queue, whilst 
awaiting the result of the online authorisation of the first payment transaction; 

using the established link to the acquirer to transmit a request for online 
authorisation for the second payment transaction using the payment transaction data 
stored in the queue, once the result of the online authorisation request for the first 
payment transaction has been received. 

26. A method according to Claim 26, wherein the storing step comprises storing 
further transaction data in the queue relating to other concurrent payment transactions 
whilst the telecommunications link is still established and in use. 

a. 

27. A method according to Claim 27, further comprising: 

removing data relating to a concurrent payment transaction from the queue once 
an authorisation result for that transaction has been received; 
checking the contents of the queue; and 

relinquishing the established link with the acquirer once there is no further 
transaction data stored in the queue, after the result of the online authorisation request for 
the last transaction has been received. 

28. A method according to Claim 27 or 28, further comprising: 

considering the acquirers to which the other concurrent payment transactions 
relate, and 

wherein the storing step comprises storing only that transaction data in the queue 
which is directed to the same acquirer as the first payment transaction. 

29. A method according to Claim 29, further comprising storing transaction data 
which relates to a different acquirer in a respective queue related to that acquirer for 
subsequent transmission thereto. 

30. A method according to any of Claims 26 to 30, further comprising creating one or 
more software session instances for each payment transaction requiring online 
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authorisation, the software session instances controlling the establishing, transmitting, 
storing and using steps for that transaction. 

31. A method according to any of Claims 26 to 31, further comprising receiving 
5 concurrent payment transaction data from a plurality of remote terminals. 

32. A method according to Claim 32, wherein the receiving step comprises receiving 
the payment transaction data via wireless communication links from the plurality of 
remote terminals. 

10 

33. * A method according to any of Claims 26 to 33, further comprising controlling a 
user interface for the input and output of payment transaction data and storing the 
payment transaction data in a database for accounting procedures. 

15 34. A method according to any of Claims 26 to 34, further comprising determining 
whether an online authorisation is necessary by comparing the amount of the transaction 
with a predetermined floor limit. 

35. A method according to any of Claims 26 to 37, further comprising determining 
20 which ones of the payment transactions stored in the queue are to be processed next. 

36. A method according to Claim 38, wherein the determining step comprises 
processing the payment transactions in order of length of time in the queue. 

25 37. A method according to Claim 32 or any of Claims 33 to 39 as dependent from 
Claim 32, further comprising receiving a payment transaction authorisation and routing 
the authorisation to the appropriate remote terminal. 

38. A method according to Claim 40, wherein the receiving step comprises receiving 
30 an authorisation code and the routing step comprises routing the code to the appropriate 
remote terminal. 
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39. A method of authorising concurrent payment transactions with a first and a 
second acquirer, the method comprising a method of authorising concurrent payment 
transactions from a first acquirer according any of Claims 25 to 41, 

5 wherein the storing step comprises: 

storing data relating to further concurrent payment transactions in the queue and a 
further queue in dependence upon the acquirer to which the payment transaction relates, 
whilst awaiting the result of the online authorisation for the first payment transaction; 
the method further comprising: 
10 relinquishing the established link with the first acquirer once there are no further 

transaction data requests stored in the queue, after the result of the online authorisation 
request for the last transaction to the first acquirer has been received; and 

establishing a link with the second acquirer via the telecommunications network 
and transmitting a request for an online authorisation of a further payment transaction 
15 using received payment transaction data stored in the further queue. 

40. A method of authorising concurrent payment transactions with an acquirer, the 
method comprising: 

receiving data relating to a first and second payment transactions from one or 
20 more remote terminals; 

storing the data relating to the second payment transaction in a queue; 
establishing a link with the acquirer via a telecommunications network and 
transmitting a request for online authorisation for the first payment transaction using the 
received first payment transaction data; 
25 using the established link to the acquirer to transmit a request for online 

authorisation for the second payment transaction, using the received second payment 
transaction data, once the result of the online authorisation request for the first transaction 
has been received; and 

relinquishing the established link with the acquirer after the result of the online 
30 authorisation request for the second transaction has been received. 
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41. A method of authorising concurrent payment transactions with an acquirer, the 
method comprising: 

establishing a link with the acquirer via a telecommunications network; 

storing data relating to at least one concurrent payment transaction, required for 
5 seeking an online authorisation, in a queue; 

using the established link to the acquirer to sequentially transmit requests for and 
receive results of online authorisations relating to each of the concurrent payment 
transactions until the queue is empty. 

10 42. An apparatus for authorising concurrent payment transactions with an acquirer, 
the apparatus comprising: 

communication means arranged to establishing a link with the acquirer via a 
telecommunications network; 

transmitting means arranged to transmit a request for an online authorisation of a 
15 first payment transaction over the link using received payment transaction data; and 

a store for storing data relating to a second and other concurrent payment 
transactions in a queue, whilst awaiting the result of the online authorisation of the first 
payment transaction; 

the transmission means being arranged to use the established link to the acquirer 
20 to transmit a request for online authorisation for the second payment transaction using the 
payment transaction data stored in the queue of the store, once the result of the online 
authorisation request for the first payment transaction has been received, 

43. An apparatus according to Claim 45, wherein the transmission means comprises a 
25 finite state machine. 

44. An apparatus according to Claim 45 or 46, further comprising: 

means for removing data relating to a concurrent payment transaction from the 
queue once an authorisation result for that transaction has been received; and 
30 wherein the transmission means is arranged to check the contents of the queue 

and relinquish the established link with the acquirer once there is no further transaction 

43 



data stored in the queue, after the result of the online authorisation request for the last 
transaction has been received. 

45. An apparatus according to any of Claims 45 to 47, further comprising: 
selecting means for considering the acquirers to which other concurrent payment 

transactions relate, the selection means being arranged to select for storage in the queue 
only that transaction data which is directed to the same acquirer as the first payment 
transaction. 

46. An apparatus according to Claim 48, wherein the selecting means is arranged to 
plaee transaction data which relates to a different acquirer in a respective queue in the 
store that is related to that acquirer for subsequent transmission thereto. 

47. An apparatus according to Claim 48 or 49, further comprising one or more 
software session instances for each payment transaction requiring online authorisation, 
the software session instances forming part of the transmission means, and the selecting 
means. 

48. An apparatus according to any of Claims 45 to 50, further comprising a plurality 
of remote terminals for receiving concurrent payment transaction data. 

49. An apparatus according to Claim 5 1 , wherein the plurality of remote terminals are 
operatively coupled to the communication means, the transmission means and the store 
via a plurality of wireless communication links. 

50. A system for implementing and authorising a payment transaction, the system 
comprising: 

a payment transaction apparatus according to any of Claims 45 to 52; 
an acquirer apparatus arranged to receive a request for an online authorisation of a 
payment transaction from the payment transaction apparatus, to authorise the payment 
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transaction at the transaction value and to transmit an authorisation confirmation over the 
telecommunications network to the payment transaction apparatus. 

51. An apparatus, system or method substantially as described herein with reference 
5 to Figures 2 to 13a of the accompanying drawings. 
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EP 1 001 388 A2 


(FUJITSU) electronic transaction apparatus 




X 


US 6 019 393 A 


(LOEBNER) a sheet for recording a gratuity, see 
whole document especially column 2 lines 8-18, 
column 3 line 45 et seq 


1-24 


A 


US 4 396 985 A 


(OMRON) electronic cash register system for food 
dispensing business, see column 11 line 27 et seq 
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